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Abstract 

A trie is a search tree scheme that employs the structure of search keys to organize in¬ 
formation. Tries were originally devised as a means to represent a collection of records 
indexed by strings over a fixed alphabet. Based on work by C.P. Wadsworth and others, 
R.H. Connelly and F.L. Morris generalized the concept to permit indexing by elements 
of an arbitrary monomorphic datatype. Here we go one step further and define tries and 
operations on tries generically for arbitrary first-order polymorphic datatypes. The deriva¬ 
tion is based on techniques recently developed in the context of polytypic programming. It 
is well known that for the implementation of generalized tries nested datatypes and poly¬ 
morphic recursion are needed. Implementing tries for polymorphic datatypes places even 
greater demands on the type system: it requires rank-2 type signatures and higher-order 
polymorphic nested datatypes. Despite these requirements the definition of generalized 
tries for polymorphic datatypes is surprisingly simple which is mostly due to the frame¬ 
work of polytypic programming. 


All generalizations are dangerous, even this one. 

— Alexandre Dumas 


1 Introduction 

The concept of a trie was introduced by A. Thue in 1912 as a means to represent a 
set of strings, see (Knuth, 1998). In its simplest form a trie is a multiway branching 
tree where each edge is labelled with a character. For exam¬ 
ple, the set of strings {ear, earl, east, easy, eye} is represented 
by the trie depicted on the right. Searching in a trie starts at 
the root and proceeds by traversing the edge that matches the 
first character, then traversing the edge that matches the second 
character, and so forth. The search key is a member of the repre¬ 
sented set if the search stops in a node which is marked—marked 
nodes are drawn as filled circles on the right. Tries can also be 
used to represent finite maps. In this case marked nodes addi¬ 
tionally contain values associated with the strings. Interestingly, 
the move from sets to finite maps is not a mere variation of the theme. As we shall 
see it is essential for the further development. 






R. Hinze 


At a more abstract level a trie can be seen as a composition of finite maps. Each 
collection of edges, descending from the same node, constitutes a finite map sending 
a character to a trie. With this interpretation in mind it is relatively straightforward 
to devise an implementation of string-indexed tries. For concreteness, programs will 
be given in the functional programming language Haskell 98 (Peyton Jones et al, 
1999). If strings are defined by the following datatype 

data Str = Nil \ Cons Char Str , 
we can represent string-indexed tries as follows. 

data MapStr v = TrieStr (Maybe v ) (MapChar (MapStr v )) 

The first component of the constructor TrieStr contains the value associated with 
Nil. Its type is Maybe v instead of v, since Nil may not be in the domain of the 
finite map. In this case the first component equals Nothing. The second component 
corresponds to the edge map. To keep the example manageable we assume that a 
suitable data structure, MapChar, and an associated look-up function lookupChar 
are predefined. Now, to lookup a non-empty string, say, Cons c s we lookup c in 
the edge map obtaining a trie which is then recursively searched for s. 


lookupStr 

lookupStr Nil (TrieStr Nothing tc) 
lookupStr Nil (TrieStr (Just v) tc) 
lookupStr (Cons c s) (TrieStr tn tc) 


Str —» MapStr v —> V 
error "not found" 

(lookupStr s o lookupChar c) tc 


Based on work by C.P. Wadsworth and others, R.H. Connelly and F.L. Morris 
(1995) have generalized the concept of a trie to permit indexing by elements of 
an arbitrary monomorphic datatype. The definition of lookupStr already gives a 
clue how a suitable generalization might look like: the trie TrieStr tn tc contains a 
finite map for each constructor of the datatype Str-, to lookup Cons c s the look-up 
functions for the components, c and s, are simply composed. The type constructor 
Maybe can be seen as implementing finite maps over the unit datatype. Generally, if 
we have a datatype with k constructors, the corresponding trie has k components. 
To lookup a constructor with n components, we must select the corresponding 
finite map and compose n look-up functions of the appropriate types. To illustrate, 
consider the datatype of external search trees. 


data Bin = Leaf Str \ Node Bin Char Bin 
The trie for external search trees is given by 


data MapBin v = TrieBin (MapStr v) 

(MapBin (MapChar (MapBin v))) . 

The type MapBin is an instance of a so-called nested datatype (nest for short). The 
term ‘nested datatype’ has been coined by R. Bird and L. Meertens (1998) and 
characterizes polymorphic datatypes whose definition involves ‘recursive calls’— 
MapBin (MapChar (MapBin v)) in the example above—which are substitution 
instances of the defined type. Functions operating on nested datatypes are known 
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to require a non-schematic form of recursion, called polymorphic recursion (Mycroft, 
1984). The look-up function on external search trees may serve as an example. 

lookupBin :: Bin — > MapBin v —> v 

lookupBin (Leaf s) (TrieBin tl tn) = lookupStr s tl 
lookupBin (Node i c r) (TrieBin tl tn) 

= (lookupBin l o lookup Char c o lookupBin r) tn 
Looking up a node involves two recursive calls. The second, lookupBin r, is of type 
Bin —» MapBin ( MapChar (MapBin «)) ■—» MapChar (MapBin v) which is a sub¬ 
stitution instance of the declared type. Haskell allows polymorphic recursion only 
if an explicit type signature is provided for the function (s). The rationale behind 
this restriction is that type inference in the presence of polymorphic recursion is 
undecidable (Henglein, 1993). 

Note that it is absolutely necessary that MapBin and lookupBin are paramet¬ 
ric with respect to the codomain of the finite maps. If we restricted the type of 
lookupBin to Bin —» MapBin aAaI.s for some fixed type s, the definition would no 
longer type-check. This also explains why the construction does not work for the 
finite set abstraction. 

From the discussion above it should be clear how to define tries for arbitrary 
monomorphic datatypes. In this paper we go one step further and show how to gen¬ 
eralize the concept to arbitrary first-order polymorphic datatypes. We will answer 
in particular the intriguing question what the generalized trie of a nested datatype 
looks like. Note that this question is not only of theoretical but also of practical 
interest. A number of data structures, such as 2-3 trees or red-black trees, have re¬ 
cently been shown to be expressible by nested declarations. R. Bird and R. Paterson 
(1998) use a nested datatype for expressing de Bruijn notation. Now, if a look-up 
structure for de Bruijn terms is required, say, to implement common subexpression 
elimination, we are confronted with the problem of constructing generalized tries 
for a nested datatype. 

To develop generalized tries for polymorphic datatypes we will employ the frame¬ 
work of polytypic programming. In short, a generic or polytypic function is one 
which is defined by induction on the structure of types. A simple example for a 
polytypic function is flatten :: f a —> [a] which traverses an element of fa and 
collects all elements of type a from left to right in a list. The function flatten can 
sensibly be defined for each polymorphic type and it is usually a tiresome, routine 
matter to do so. A polytypic programming language enables the user to program 
flatten once and for all times. The specialization of flatten to concrete instances 
of / is then handled automatically by the system. Polytypic programming can be 
surprisingly simple. In a companion paper (Hinze, 1999) we show that it suffices 
to define a polytypic function on predefined types, type variables, sums, and prod¬ 
ucts. This information is sufficient to specialize a polytypic function to arbitrary 
datatypes including mutually recursive and nested datatypes. 

Generalized tries make a particularly interesting application of polytypic pro¬ 
gramming. The central insight is that a trie can be considered as a type-indexed 
datatype. This makes it possible to define tries and operations on tries generically 
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for arbitrary polymorphic datatypes. We already have the necessary prerequisites 
at hand: we know how to define tries for sums and for products. A trie for a sum is 
a product of tries and a trie for a product is a composition of tries. The extension 
to arbitrary datatypes is then uniquely defined. 

We have seen that nested datatypes and polymorphic recursion are necessary 
for the implementation of generalized tries. Implementing tries for polymorphic 
datatypes, especially nested datatypes, places even greater demands on the type 
system: it requires rank-2 type signatures (McCracken, 1984), higher-order poly¬ 
morphic datatypes (Jones, 1995), and higher-order polymorphic nests. Fortunately, 
all major Haskell system provide the necessary extensions. 

The rest of this paper is structured as follows. In Section 2 we briefly review 
the theoretical background of polytypic programming. A more detailed account is 
given in (Hinze, 1999). Section 3 applies the technique to implement a finite map 
abstraction based on generalized tries. Section 4 discusses variations of the theme. 
Finally, Section 5 reviews related work and points out a direction for future work. 


2 A polytypic programming primer 
2.1 Datatypes 

A polytypic function is one which is parameterised by a datatype. The polytypic 
programming primer therefore starts with a brief investigation of the structure 
of types. The following definitions will serve as running examples throughout the 
paper. 


data List a 
data Bintree a\ a 2 
data Fork a 
data Perfect a 
data Sequ a 


Nil | Cons a (List a) 

Leaf a\ \ Node (Bintree ai a 2 ) a-2 (Bintree a\ <12) 

Fork a a 

Null a | Succ (Perfect (Fork a)) 

Empty | Zero (Sequ (Fork a)) \ One a (Sequ (Fork a)) 


The meaning of these datatypes in a nutshell: the first equation defines the ubiq¬ 
uitous datatype of polymorphic lists; Bintree encompasses external binary search 
trees. The types Perfect and Sequ are examples for nested datatypes: Perfect com¬ 
prises perfect binary leaf trees (Dielissen & Kaldewaij, 1995) and Sequ implements 
binary random-access lists (Okasaki, 1998). Both definitions make use of the aux¬ 
iliary datatype Fork whose elements may be interpreted as internal nodes. 

Haskell’s data construct combines several features in a single coherent form: 
sums, products, and recursion. Using more conventional notation (‘+’ for sums and 
‘ x ’ for products) and omitting constructor names we obtain the following emaciated 
recursion equations. 


List a 

Bintree a 2 
Fork a 
Perfect a 
Sequ a 


1 -I- a x List a 

d] + Bintree ai a 2 x a 2 x Bintree <i\ a 2 
a x a 

a + Perfect (Fork a ) 

1 + Sequ (Fork a) + a x Sequ (Fork a) 
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/\ A o 


Perfect a 


Fig. 1 Types interpreted as infinite type expressions. 


In the following we treat 1, ‘+’, and x 1 as if they were given by the following 
datatype declarations. 


data 1 =0 

data ai + 02 = Ini ai \ Inr a 2 

data a\ x a 2 = («i, ^2) 

Now, the central idea of polytypic programming is that the set of all types— 
or rather, the set of all type expressions itself can be modelled by a datatype. 
Assuming a fixed set of type variables A = {ai,a 2 ,a3,...} and a set of primitive 
type constructors P = {1, Int, ...,+, x } type expressions can be seen as defined by 
the following grammar. 

T = A \ P (T,...,T) 

The type F(ti,... ,t n ) denotes the application of an n-ary type constructor to n 
types. We omit the parenthesis when n ^ 1. We also write ti + f 2 for + (ti,t 2 ) 
and similarly ti x to. Finally, we abbreviate a\ to a when defining unary type 
constructors. 

The question remains how recursive types are modelled. The answer probably 
comes as no surprise to the experienced Haskell programmer: recursive types are 
modelled by infinite type expressions! Figure 1 displays the infinite type expressions 
defined by the equations for List and Perfect. 


2.2 Polytypic definitions 

A polytypic function is defined by induction on the structure of types. In general, 
the definition takes the following form. 

poly(t) :: r(t) 
poly{ai) = poly a . 

poly(F(t!,... ,t n )) = poly F {poly <*i>, - - -, poly(t n )) 

The type parameter is written in angle brackets to distinguish it from ordinary 
parameters. If t is an n-ary type constructor, poly a . must be specified for 1 ^ i ^ n. 
Furthermore, an equation must be given for each primitive type constructor F e P. 
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As an example, the function flatten , which listifies a given structure, can be 
defined as follows. 


flatten(t) 
flatten{l) a 
flatten{Int) a 
flatten(a) a 
flatten(ti + t 2 ) (Ini ai) 
flatten(ti + t 2 ) (Inr a 2 ) 
flatten(ti x t 2 ) (a 2 , a 2 ) 


Ma.t a > [a] 

[] 

[] 

[a] 

flatten(fl) 
flatten {t 2 ) a 2 

flatten (fl) -H- flatten {t 2 ) a 2 


The first two equations specify the action of flatten on nullary type constructors, ie 
flatten t = \a -> [] for each t £ {1, Int, ...}. The third equation defines flatten a = 
A a —> [a]. Finally, flatten + and flatten x are given by 


flatten + {ipi,ip 2 ) = A a —t case a of {Ini a\ —» ai;Inr a 2 —> ip 2 a 2 ] 

flatten x ((p!,ip 2 ) = A(ai, a 2 ) -» ipi ai -H- a 2 . 


This information is sufficient to define a unique function flatten(t) for each (unary) 
type expression t (Courcelle, 1983). Of course, since t may be infinite—and usually 
is—we require that types are interpreted by complete partial orders and functions 
by continuous functions between them. Both conditions are usually met. 

The use of infinite type expressions as index sets for polytypic functions dis¬ 
tinguishes our approach from previous ones (Jeuring & Jansson, 1996; Jansson 
& Jeuring, 1997), which are based on the initial algebra semantics of datatypes. 
Briefly, our approach has two major advantages: it is simpler (the programmer 
must consider less cases) and it is more general (it covers all first-order polymor¬ 
phic datatypes). We refer the interested reader to (Hinze, 1999) for a more detailed 
account of the pros and cons. 


2.3 Specializing polytypic definitions 

The main purpose of a polytypic programming system is to specialize a polytypic 
function poly(t) for different instances of t. Unfortunately, the specialization cannot 
be based on the inductive definition of poly(t) —at least, not directly. Consider the 
following attempt to specialize poly {Perfect a): 

poly {Perfect a) 

= poly{a + Perfect {Fork a)) 

= poly + {poly a , poly {Perfect {Fork a))) 

= poly + {poly a , poly {Fork a + Perfect {Fork {Fork a)))) 

= poly + {poly a , poly + {poly {Fork a), poly {Perfect {Fork {Fork a))))) 

To define poly{Perfect a) we require poly{Perfect (Fork n a)) for each n ^ 1. It is 
probably clear that in general we cannot hope to obtain a finite representation of 
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poly(t) this way. Instead, we must base the specialization on the representation of 
types, ie on the datatype declarations themselves, which are by necessity finite. 

To exhibit the structure of datatype declarations more clearly we shall rewrite 
them as functor equations. Functor expression of arity n are given by the following 
grammar. 

F n = nf \P n \F k ■ (Fff,..., FJ?) 

By II” we denote the n-ary projection functor selecting its *-th component. For 
n = 1 and n = 2 we use the following more familiar names: Id = U\, Fst = Ilf, and 
Snd = II|. Elements of P n are predefined functors of arity n, ie P° = {1, Int ,...} 
and P 2 = {+, x}. The expression F ■ (F 1 ,..., F k ) denotes the composition of an 
k -ary functor F with functors F t , all of arity n. We omit the parenthesis when n = 1 
and we write Kt instead of t • () when n = 0. Finally, we write /i + / 2 for + •(/i, / 2 ) 
and similarly f\ x / 2 . 

Here are the datatype definitions of Section 2.1 rewritten as functor equations. 


List 

= K 1 + Id x List 

Bintree 

= Fst + Bintree x Snd x Bintree 

Fork 

= Id x Id 

Perfect 

= Id + Perfect ■ Fork 

Sequ 

= K1 + Sequ ■ Fork + Id x Sequ ■ 


In essence, functor equations are written in a compositional or ‘point-free’ style 
while data definitions are written in an applicative or ‘pointwise’ style. 

Now, the central idea is to define, for each arity n, an n-ary function poly n (f) 
satisfying 

poly n {f) (poly(h),...,poly(t n )) = poly(f(ti,...,t n )) . 

We let function follow type: / is an n-ary functor mapping the types .f„ 

to f(ti ,..., t n )\ likewise poly n (f) is an n-ary function mapping the polytypic func¬ 
tions poly(ti),... ,poly(t n ) to poly(f(ti,..., t n )). It can be shown that the following 
definition satisfies the condition above: 


PolVnif) 

poly n (Ui) 
poly n (F) 
poly n (f ■ (fli> ■ • ■ ,9k)) 


^)X"'Xr(t n )4T(/ 


poly F 

poly k (f) * ( poly n (gi ), • ■ • ,poly n (gk )) ■ 


where -K\ (ip \,..., ip n ) = ipi is the i-th projection function and V denotes n-ary 
composition defined by (p * (<pi ,..., <p n ) = Xa —» ip (ipi a,...,tp n a). Note that 
<p* (ipi) = ipoip\ when n = 1 Furthermore note, that the definition of poly n (f) is 
inductive on the structure of functor expressions. On a more abstract level we can 
view poly n as an interpretation of functor expressions: H, is interpreted by tt,;, F 
by poly F , and *•’ by V. 
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Now, setting U = at we can define poly in terms of poly n . 
poly(f) :: r(f) 

poly(f(a 1 ,...,a n )) = poly n (f) (poly ai ,..., poly a J 

By now we have the necessary prerequisites at hand to define the specialization 
of a polytypic function poly(f(ai,... ,a n )) for a given instance of /. Assume that 
the type constructor is defined by the system of equations (/i = e\,.. ., f m = e m ) 
with / = fi for some i. For each equation fi = e\ , where /, is an fc-ary type 
constructor, a function definition of the form poly k (fi) = poly k (ei) is generated. 
The expression poly k (ei) is given by the inductive definition above, additionally 
setting poly k (fi) = polyJt-fi, where polyJt-fi is a new function symbol. Finally, 
the defining equation for poly.f, ie poly-f = polyjri-f ( poly ai ,... ,poly an ), must be 
added. 

Let us apply the above framework to specialize flatten(t) for t = Perfect. Since 
flatten(t) has a polymorphic type, the auxiliary functions flatten n (f) take poly¬ 
morphic functions to polymorphic functions. We have, for instance, 


flatten^) :: (Va.t a (Vo./ (t a) . 

In other words, flatten 1 (f) has a rank-2 type signature (McCracken, 1984). 

The specialization proceeds entirely mechanically. Using the original constructor 
names and abbreviating type names to their first letter we obtain 


flattenP 

flattenP 

flattenlF 

flattenlF f (Fork ai a 2 ) 
flattenlP 

flattenlP f (Null a) 
flattenlP f (Succ a) 


Perfect a -> [a] 
flattenlP (A a > [a]) 

(Va./. a > [a]! 4 -# If!a.Fork (t a) > [a]) 

/ ffli -H- / 

(Va./. a > [a]| : *4 (Va.Perfect (t a) > [a]) 

/« 

flattenlP (flattenlF f) a . 


Flattening a perfect tree operates in two stages: while recursing flattenlP constructs 
a tailor-made flattening function flattenlF * / of type Va.Fork 1 t a —» [a] which is 
eventually applied in the base case. 

Remark. Unfortunately, the above definitions pass neither the Hugs nor the GHC 
type-checker though both accept rank-2 type signatures. The reason is that Haskell 
provides only a limited form of type constructor polymorphism. Consider the subex¬ 
pression flattenlF f in the last equation. It has type Va.Fork (t a ) —» [a] which 
is not unifiable with the expected type Va.t' a —> [a]. Since Haskell deliberately 
omits type abstractions from the language of type constructors (Jones, 1995), we 
cannot instantiate t' to Am ■ _*# Fork (t u). Fortunately, there is a way out of this 
dilemma. If we assign the following types to flattenlF and flattenlP 


flattenlF :: (v -»[<«]) > (Fork v > [ ui') 
flattenlP :: (v i#:|ia]) -» (Perfect v ->■ [w]) , 

the above definitions type-check. This trick works as long as the definition of poly{t) 
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does not involve polymorphic recursion (in Section 3.2 we will get to know a poly¬ 
typic function which is polymorphically recursive). □ 


3 Tries generically 

In this section we apply the framework of polytypic programming to implement gen¬ 
eralized tries generically for all first-order polymorphic datatypes. We have already 
mentioned the basic idea that generalized tries can be considered as a type-indexed 
datatype. To put this idea in concrete terms we will define a datatype 

Map{*) :: * -» * , 

which assigns a type constructor of kind 4 * to each type constructor of kind *. 
The type Map(k) v represents the set of finite maps from k to v. Based on this 
representation we will implement the following operations. 


empty (k) 
single (k) 
lookup (k) 
insert(k) 
merge(k) 


Mv.Map(k) v 

\/v.k x v —^ Map(k) v 

\/v.k —» Map(k) v —> Maybe v 

\/v.(v —> v —> v) ^ k x v —> (Map(k) v —> Map(k) v) 
\/v.(v —» d —» v) —» ( Map(k) v —» Map(k) v —» Map(k) v ) 


The signature of lookup{k) deviates slightly from the one used in the introduction 
to this paper: the look-up function returns a value of type Maybe v instead of v to 
be able to signal that a key is unbound. The functions insert(k) and merge(k) take 
as a first argument a so-called combining function, which is applied whenever two 
bindings have the same key. Typically, the combining form is fst or snd. For finite 
maps of type Map(k) Int addition may also be a sensible choice. Interestingly, we 
will see that the combining function is not only a convenient feature for the user, 
it is also necessary for defining insert(k) and merge(k) generically for all types! 


3.1 Type-indexed tries 

Mathematically speaking, generalized tries are based on the following isomorphisms, 
also known as laws of exponentials. 

1 —tfln v = Maybe v 

( kl + kz) —»fin 11 — (k\ —»fin v) X (k>2 —»fin v) 

( ki X *2) —»fj n V = kl —>fin (*2 —»fin v) 

As Map(k) v represents the set of finite maps from k to v, ie k —>-fi n v, the isomor¬ 
phisms above can be rewritten as defining equations for Map(k). 

Map( 1) = Maybe 

Map(Int) = 

Map(k 1 + hi) = 

Map(ki x ka) = 


Patricia.Diet 
Map(ki) x Map(k 2 ) 
Map(ki) ■ Map(k 2 ) 
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We assume the existence of a suitable library implementing finite maps with integer 
keys. Such a library could be based, for instance, on a data structure known as a 
Patricia tree (Okasaki & Gill, 1998). This data structure fits particularly well in 
the current setting since Patricia trees are a variety of tries. For clarity we will 
use qualified names when referring to entities defined in the hypothetical module 
Patricia. 

Building upon the techniques developed in Section 2.3 we can now specialize 
Map{k) for a given instance of k. That is, for each functor / of arity n we will 
define an n-ary higher-order functor Map n {f). For n = 1 we have, for instance, 

Ma Pl {*^*} :: (* -> *) -» (* -» *) . 

The type constructor Map 1 (f) is the generalized trie of a polymorphic datatype. 
It takes as argument the generalized trie of the base type, say, a and yields the 
generalized trie off a. It may come as a surprise that the framework for specializing 
type-indexed functions is also applicable to type-indexed datatypes. The reason 
is quite simple: the definition of poly n (f) requires only two operations, namely 
projection and composition. However, both operations are also available in the 
world of functors and higher-order functors. 

Let us specialize Map n (f) to the datatypes listed in Section 2.1. For better read¬ 
ability we abbreviate type names to their first letter and omit the arity of functors, 
ie we write MapL instead of MaplList. 


MapL m 
MapB (mi, m^) 
MapF m 
MapP m 
MapS m 


Maybe x m ■ MapL m 

mi x MapB (mi, m2) • m2 • MapB (mi, m2) 
m x MapP (MapF m) 

Maybe x MapS (MapF m) x m ■ MapS (MapF m) 


Since Haskell permits the definition of higher-order polymorphic datatypes, the 
higher-order functors above can be directly coded as datatypes. All we have to do 
is to bring the equations into an applicative form. 


data MapL m v = TrieL (Maybe v) (m (MapL m v)) 

data MapB mi m 2 v = TrieB (mi v) 

(MapB mi m 2 (m 2 (MapB mi m 2 v))) 

These types are the polymorphic variants of MapStr and MapBin defined in the 
introduction, ie we have MapStr = MapL MapChar (since Sir = List Char) and 
MapBin = MapB MapStr MapChar (since Bin = Bintree Str Char). Things 
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become interesting if we consider nested datatypes. 

data MapF m v = TrieF (m (m v )) 
data MapP m v = TrieP (m v) 

(MapP (MapF m) v) 
data MapS m v = TrieS (Maybe v) 

(MapS (MapF m ) v) 

(m (MapS (MapF m ) w)) 

The generalized trie of a nested datatype is a higher-order polymorphic nested 
datatype! The nest is higher-order polymorphic since the type parameter which 
is instantiated in a recursive call ranges over type constructors of kind * *. 

By contrast, MapB is a first-order polymorphic nest since its instantiated type 
parameter has kind *. It is quite easy to produce generalized tries which are 
both first- and higher-order nests. If we change the type of Sequ’s third con¬ 
structor to One (Sequ (Fork a)) a, then the third component of TrieS has type 
MapS (MapF m) (m v ) and MapS is consequently both a first- and a higher-order 
nest. 


3.2 Empty and singleton tries 

The empty trie is given by 


empty (k) 
empty (1) 
empty (Int) 
empty (h + k 2 ) 
empty(k\ x k 2 ) 


\/v.Map(k) v 
Nothing 
Patricia. empty 
(empty(k{), empty(k^)) 
empty(k\) . 


The definition already illustrates several interesting aspects of programming with 
generalized tries. To begin with the polymorphic type of empty(k) is necessary 
to make the definition work. Consider the last equation: empty(h x k 2 ), which 
is of type \/v.Map{ki) (Map(k 2 ) v), is defined in terms of empty(k\), which is of 
type \/v.Map(ki) v. That means that empty(k\) is used polymorphically. In other 
words empty(k) makes use of polymorphic recursion! By contrast, the definition 
of flatten(t) given in Section 2.2 also type-checks when the type is restricted to 
t s —> [a] for some fixed type s. 

Since empty(k) has a polymorphic type, empty n (f) takes polymorphic values to 
polymorphic values. We have, for instance, 


empty 1 (f) :: (\/v.Map(k) v) -4 (\/v.Map(f k) v) 

To obtain a signature which is expressible in Haskell we employ the specification of 
Map n (f), ie Map(f(ki,... ,k n )) = Map n (f) (Map(ki ),..., Map(k n )), additionally 
setting Map(k) = m where m is a fresh type variable. 


empty x (j) :: (\/v.m v) —» ( \/v.Map 1 (f) m v ) 
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Let us take a look at some examples. 1 


emptyL 

:: (Vv.m 

> MapL m w 

emptyL e 

= TrieL Nothing e 

emptyF 

:: (Vv.m 

.if—» MapF m w 

emptyF e 

= TrieF 

e 

emptyP 

:: (Vv.m 

> MapP m w 

emptyP e 

= TrieP 

e (emptyP (emptyF e)) 


The second function, emptyF , illustrates the polymorphic use of the parameter: 
e has type Mv.m v but is used as an element of m (m w). The last defini¬ 
tion employs ‘higher-order polymorphic’ recursion: the recursive call is of type 
( Nr.MapF m v) -» MapP (MapF m ) w which is a substitution instance of the 
declared type. The function emptyP illustrates another point: the implementation 
of generalized tries relies in an essential way on lazy evaluation. As an example, 
consider the empty trie for Perfect Int, which is represented by the infinite tree 
(abbreviating Patricia.empty to e) 

TrieP e (TrieP (TrieF e) (TrieP (TrieF (TrieF e)) ...)) . 

In Section 4.1 we shall discuss a slightly modified representation of generalized tries 
which avoids this problem. 

The singleton trie which contains only a single binding is defined as follows. 


single(k) 
single{1) (Q,v) 
singlelint) (i,v) 
single{ki + k 2 ) (Ini fa, v) 
single{ki + k 2 ) (Inr i 2 , v) 
single(k\ x k 2 ) ((*i, *2), ^) 


Vv.k x v -» Map{k) v 
Just v 

Patricia.single (i,v) 

( single(k\) (fa, v), empty(ki)) 
(empty(k\), single(k 2 ) (fa,v)) 
single(ki) (fa, single(k 2 ) (fa,v)) 


The definition of single(k) is interesting because it falls back on empty(k) in the 
third and the fourth equation. This necessitates that single n (f) is parameterised 
both with single(k) and with empty(k). For n = lwe obtain the type signature 


single 1 (f) :: (Vv.m v ) 

—» (Vv.k x v —> m v) 

—> (Vv./ l;x«-> Map 1 (f) m v) . 

Let us again specialize the polytypic function to lists and perfect trees. To improve 
readability we will henceforth present the instances without their type signatures— 
which are, nonetheless, mandatory. 

singleL e s (Nil, v) = TrieL (Just v) e 

singleL e s (Cons i is, v) = TrieL Nothing (s (i, singleL e s (is, v ))) 

singleF e s (Fork fa %.p) = TrieF (s (fa,s (i 2 ,v))) 


1 Note that we use Hugs/GHC syntax for universal quantification (Peyton Jones, 1998), which 
forces us to write (Vu.m v) *4 MapL m w instead of (Vu.m v) ( Vv.MapL m v). 
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singleP e s (Null i, v) = TrieP (s (i, v)) (emptyP (emptyF e)) 

singleP e s (Succ i,v) = TrieP e (singleP (emptyF e) (singleF e s ) (i,w)) 

The function singleF illustrates that the ‘mechanically’ generated definitions can 
sometimes be slightly improved. Since the definition of Fork does not involve sums, 
singleF does not require its first argument which could be safely removed. 


3.3 Lookup 

The look-up function implements the scheme discussed in the introduction. 


lookup (k) 
lookup (1) () t 
lookup (Int) i t 

lookup(ki + k 2 ) (Ini fi) (fi, t 2 ) 
lookup{ki + k 2 ) (Inr *2) (Ai, h) 
lookup(ki x k 2 ) (*i,*2) h 


Mv.k > Map(k) 0 *4 Maybe v 
t 

Patricia.lookup i t 
lookup(ki) ti 
lookup (hi) *2 h 

do { A2 <— lookup (ki) ii t\; lookup(k^) *2 £2} 


On sums the look-up function selects the appropriate map; on products it ‘com¬ 
poses’ the look-up functions for the components. Since lookup(k) has result type 
Maybe v, composition amounts to monad or Kleisli composition (Bird, 1998). Defin¬ 
ing 

(mi O m 2 ) fli = do { a 2 5C*'m 1 ap, m 2 a 2 } 
we may write the last equation more succinctly as 


lookup(ki x k 2 ) (*i,*2) = lookup(ki) O lookup(k 2 ) *2 • 

Specializing lookup (k) to concrete instances of k is by now probably a matter of 
routine. Here is lookup 1 (f) , s type signature. 


lookup 1 (f) :: ( Mv.k —> m v —> Maybe v) 

-»■ (Vi>./ k -> Map 1 (f) m v -» Maybe v ) . 

For lists and perfect trees we obtain 


lookupL l Nil (TrieL tn tc ) 
lookupL £ (Cons i is) (TrieL tn tc) 
lookupF l (Fork i 2 ) (TrieF tf) 

lookupP £ (Null i) (TrieP ts tc) 
lookupP £ (Succ i) (TrieP ts tc) 


tn 

(lookupL £ is O £ i) tc 
{£ i 2 O £ <1) tf 
£ i ts 

lookupP (lookupF £) i tc . 


Note that lookupL generalizes lookupStr defined in the introduction to this paper; 
we have lookupStr s = from Just o lookupL lookupChar s where from Just is given 
by from Just (Just a) = a. The definition of lookupP employs the same recursion 
scheme as flattenlP : while recursing, lookupP constructs a tailor-made look-up 
function lookupF 1 £ of type Fork 1 k ->■ MapF * w ->■ Maybe w which is finally 
applied in the base case. 
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3.4 Inserting and merging 
Insertion is defined in terms of merge(k) and single(k). 

insert(k) :: \/v.(v —> v —> v) —> k x v —> (Map(k) v —» Map(k) v ) 

insert(k) c ( i,v ) t = merge(k) c ( single(k ) ( i,v )) t 

Note that this is not the most efficient implementation of insert(k) since singleton 
tries are in general given by infinite trees. This implies that the running time of 
insert(k) is not proportional to the size of the inserted element as one would ex¬ 
pect. The problem vanishes, however, if we employ the alternative representation 
of generalized tries to be introduced in Section 4.1. 

Merging two tries is surprisingly simple. Given an auxiliary function for combin¬ 
ing two values of type Maybe a 

combine 

combine c Nothing Nothing 
combine c Nothing (Just a') 
combine c (Just a) Nothing 
combine c (Just a) (Just a') 

we can define merge(k) as follows. 

merge(k) :: Mv.(v —> v —» v) 

fk (Map(k) v -» Map(k) v -» Map(k) v) 
merge(l) c t t 1 = combine c t t‘ 

merge(Int) c t t 1 = Patricia.merge c t t 1 

merge(k\ + fe) c (ti, h) ( t [, t^) = ( merge(k\) c t\ t[, merget^k-i) c 1 2) 

merge(k\ x & 2 ) c t t’ = merge(k\) [merget^k-i) c) t t’ 

The most interesting equation is the last one. The tries t and t 1 are of type 
Map{k 1 x kg) v = Map(k\) ( Map{kg) v). To merge them we can use merge(k\); 
we must, however, supply a combining function of type Map{k 2 ) v —» Map(kg) v 
Map^kg) v. A moment’s reflection reveals that that merge(h 2 ) c is the desired com¬ 
bining function. Using functional composition we can write the last equation quite 
succinctly as 

merge{k 1 x 1 2 ) = merge(k 1 ) o merge{k‘ 2 ) . 

The definition of merge(k) shows that it is sometimes necessary to implement op¬ 
erations more general than actually needed. If merge(k) had the simplified type 
Map(k) v -» Map(k) v Map(k) v, then we would not be able to give a defining 
equation for k = ki x k 2 . 

To complete the picture let us again specialize the merging operation for lists 
and perfect trees. To begin with here is merge 1 (f) , s type signature. 

merge±{f) :: ( \/v.(v —» v —» v) —> (m v —> m v —> m v)) 

( Vv.(v (Map 1 (f) m v -» Map 1 (f) m v -» Map 1 (f) m v)) 


> (Maybe a > Maybe a —» Maybe a) 
= Nothing 
= Just a 1 
= Just a 
= Just (c a a') , 
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The different instances of merge 1 (f) are surprisingly concise. 

mergeL m c (TrieL tn i tc\) (TrieL tn 2 tc 2 ) 

= TrieL (combine c tn\ tn 2 ) (m (mergeL m c) tc\ tc 2 ) 
mergeF m c (TrieF tf x ) (TrieF tf 2 ) 

= TrieF (m (m c) tf 1 tf 2 ) 
mergeP m c (TrieP ts\ tci) (TrieP ts 2 tc 2 ) 

= TrieP (m c tsi ts 2 ) (mergeP (mergeF m) c tc\ tc 2 ) 


4 Variations of the theme 
4-1 Spotted tries 

The representation of tries as defined in the previous section has two major draw¬ 
backs: (i) it relies in an essential way on lazy evaluation and (ii) it is inefficient. 
Both disadvantages have their roots in the representation of tries on sums. A trie 
on ki + k 2 is a pair of tries irrespective of whether the trie is empty or not. This 
suggests to devise a special representation for the empty trie. Technically, this is 
achieved using so-called spot products (Connelly & Lockwood Morris, 1995). 

data ai x. a 2 = Spot \ Pair a\ a 2 

Spot products are also known as optional pairs. Changing Map{k)’ s definition to 
Map(ki+k 2 ) = Map(ki) x. Map{k 2 ) 
we can now represent the empty trie in constant space. 

empty (ki + k 2 ) = Spot 

This representation is, of course, no longer unique. Therefore, we require that the 
empty trie on sums is always represented by Spot. Maintaining this invariant in our 
implementation is, however, trivial since tries never shrink. The situation would be 
different if we additionally supplied an operation for removing bindings from a trie. 
The remaining operations must be modified accordingly. 


single{k 1 + k 2 ) (Ini q. v) 
single{k 1 + k 2 ) (Inr i 2 , v) 
lookup{ki + k 2 ) k Spot 
lookup(ki + k 2 ) (Ini q) (Pair t\ t 2 ) 
lookup(ki + k 2 ) (Inr i 2 ) (Pair t\ t 2 ) 


Pair ( single{ki) (h,v)) ( empty{k 2 )) 

Pair ( empty(ki )) (single{k 2 ) (*2,«)) 

Nothing 

lookup (ki) 4 h 

lookup(k 2 ) 4 t 2 


merge(ki + k 2 ) c Spot t' = 

merge(ki + k 2 ) c t Spot = 

merge(ki + k 2 ) c (Pair ti 4) (Pair t[ 1 2 ) 


t' 

t 

Pair (merge(ki) c t\ t[) ( merge(k 2 ) c t 2 t 2 ) 


Figure 2 contains the complete code for generalized tries on binary random-access 
lists building on the above representation. Some remarks are appropriate. First of 
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{- Generalized tries for polymorphic binary random-access lists -} 


data MapS m v 

= 

SpotS | TrieS {Maybe v) 




{MapS {MapF m) v) 

{m {MapS {MapF m) v)) 

emptyS 



MapS m w 

emptyS 


= 

SpotS 

singleS 


Kj§ 

(Vu.m v) 

{Mv.k x v — ^ m v) 

Sequ k x w — > MapS m w 

singleS e s 

{Empty, v) 

= 

TrieS {Just v) emptyS e 

singleS e s 

{Zero x, v) 

= 

TrieS Nothing 

{singleS {emptyF e) {singleF e s) {x, v)) 

singleS e s 

{One i x, v) 

= 

TrieS Nothing 
emptyS 

{s {i, singleS {emptyF e) {singleF e s) {x, d))) 

lookupS 



{\/v.k —^ m v —^ Maybe v) 

Sequ k —» MapS m w Maybe w 


lookupS £ Empty {TrieS te tz to) 

= te 

lookupS £ (Zero x ) (TrieS te tz to) 

= lookupS (lookupF £) x tz 
lookupS £ (One i x) (TrieS te tz to) 

= ( lookupS ( lookupF £) x O £ i) to 

mergeS :: (Vv.(v -> v -> v) -> {m v -> m v -> m u)) 

—^ (w —^ w —^ w) —^ ( MapS m w —^ MapS m w —^ MapS m 
mergeS m c SpotS t' = t' 

mergeS met SpotS = t 

mergeS m c (TrieS te i tz\ to i) (TrieS te 2 tz 2 toi) 

= TrieS (combine c te 1 te 2) 

(mergeS (mergeF m) c tzi tz2) 

(m (mergeS (mergeF m) c) toi to^) 

{- Generalized tries for binary random-access lists over integers -} 


type MapSI 

= MapS Patricia.Diet 

emptySI 

:: MapSI v 

emptySI 

= emptyS 

singleSI 

:: Sequ Int x v —> MapSI v 

singleSI 

= singleS Patricia.empty Patricia.single 

lookupSI 

:: Sequ Int —» MapSI w —» Maybe w 

lookupSI 

= lookupS Patricia.lookup 

insertsI 

:: {v —^ v —^ v) —^ Sequ Int x v —> {MapSI v 

insertsI c b t 

= mergeSI c {singleSI b) t 

mergeSI 

:: (v Ht * »).-»• {MapSI v MapSI 

mergeSI 

= mergeS Patricia.merge 

Fig. 2 

!. Generalized tries for binary random-access lists. 


' MapSI v) 
MapSI v) 
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all, the datatype MapS is based on the functor equation 

MapS m = Maybe x. MapS (MapF m) x. m ■ MapS (MapF m) . 

For simplicity we interpret (q x . a 2 x. a 3 as the type of optional triples and not as 
nested optional pairs. 

data Bi x, a 2 x, u 3 = Spot \ Triple (q a 2 «3 
The definition of emptyS has been simplified by omitting its parameter, which is 
not required. Finally, note that we have not listed the implementation of generalized 
tries for the datatype Fork. Since Fork’s definition does not involve sums, the code 
is identical to that given in Section 3. 


4-2 Skinny tries 

Extending the idea of the previous section one step further we could additionally 
devise a special representation for singleton tries. 

data «i .x. a 2 = None \ Onlyl cq | Onlyr a 2 | Both cq cz 2 
Using, x. instead of x. has the advantage that single(k) need not refer to empty {k). 


single(ki + k 2 ) (Ini ii,v) = Onlyl (single(ki) (q, u)) 
single(ki + k 2 ) (Inr i 2 , v) = Onlyr ( single(k 2 ) (i 2 , u)) 

This representation is furthermore a bit more space economical. A potential disad¬ 
vantage is the increased number of cases one must consider when defining lookup (k) 
and merge(k). 


lookup (ki + hi) (Ini q) None 
lookup (hi + fo) (Ini q) ( Onlyl ti) 
lookup (ki + k 2 ) (Ini q) ( Onlyr t 2 ) 
lookup(ki + k 2 ) (Ini q) ( Both t\ t 2 ) 
merge(k\ + & 2 ) c ( Onlyl t\) None 
merge(k\ + & 2 ) c ( Onlyl t\) ( Onlyl t[) 
merge(k\ + k 2 ) c (Onlyl ti ) (Onlyr t' 2 ) 
merge(k\ + k^) c ( Onlyl t\) (Both t[ t 2 ) 
The remaining cases are defined accordingly. 


Nothing 
lookup {ki) q ti 
Nothing 
lookup (ki) q t\ 

Onlyl ti 

Onlyl ( merge(ki) c t\ t[) 
Both ti t 2 

Both (merge(ki) c t\ t[) t! 2 


5 Related and future work 

D.E. Knuth (1998) attributes the idea of a trie to A. Thue who introduced it 
in a paper about strings that do not contain adjacent repeated substrings. R. de 
la Briandais recommended tries for computer searching (1959). The generaliza¬ 
tion of tries from strings to elements of an arbitrary datatype was discovered 
by C.P. Wadsworth (1979) and others independently since. R.H. Connelly and 
F.L. Morris (1995) formalized the concept of a trie in a categorical setting: They 
showed that a trie is a functor and that the corresponding look-up function is 
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a natural transformation. Interestingly, despite the framework of category theory 
they base the development on many-sorted signatures which makes the definitions 
somewhat unwieldy. This paper shows that the construction of generalized tries is 
much simpler if we replace to concept of a many-sorted signature by its categorical 
counterpart, the concept of a functor. 

The first implementation of generalized tries was given by C. Okasaki in his recent 
textbook on functional data structures (1998). Tries for polymorphic types like lists 
or binary trees are represented as Standard ML functors. While this approach works 
for regular datatypes it fails for nested datatypes such as Perfect or Sequ. In the 
latter case higher-order polymorphic datatypes are indispensable. 

That said, a direction for future work suggests itself, namely to generalize tries 
to arbitrary higher-order polymorphic datatypes. To give an impression of the ex¬ 
tensions consider the standard definition of rose trees. 

data Rose k = Branch k (List (Rose k)) 

Its trie is given by 

data MapR mk v = TrieR (mk (MapL (MapR mk ) v)) . 

Now, abstracting the list functor away we obtain the following generalization of 
rose trees. 

data GRose t k = GBranch k (t (GRose t k )) 

The trie of Rose can be generalized in a similar way. 

data MapGR mt mk v = TrieGR (mk (mt (MapGR mt mk) v)) 

Note that GRose is a type constructor of kind *) 'Jjfi (* *) while its 

trie has kind ((* -» *) - 5 - (* *4- *)) =# ((* *) **£< (* -4 *)). Now, the same 

systematics can be applied to generalize the operations on MapR to operations on 
MapGR. Currently, the author is working on a suitable extension of the framework 
which allows to define polytypic functions generically for all datatypes expressible 
in Haskell. 
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